【レポート】Architecting and Building – ログデータ用のデータレイク＆分析環境をクイックに構築するには？ #AWSSummit

AWS Summit Online 2020 『AAB-03:Architecting and Building - ログデータ用のデータレイク＆分析環境をクイックに構築するには？』のセッションレポートです。

データ分析

#レポート

#AWS

#データ分析

石橋勇二

2020.09.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

皆さんこんにちは。石橋です。

2020年9月8日から9月30日までオンラインで視聴可能なクラウドカンファレンス、AWS Summit Online 2020が開催中です！！

本エントリではライブセッション「AAB-03：Architecting and Building - ログデータ用のデータレイク＆分析環境をクイックに構築するには？」のレポートをお届けします。

概要

スピーカー

アマゾンウェブサービスジャパン株式会社技術統括本部ソリューションアーキテクト 下佐粉昭
アマゾンウェブサービスジャパン株式会社技術統括本部ソリューションアーキテクト 野間愛一郎

セッション概要

ログやデータベースに色々なデータが溜まっている。できればデータを集めて分析したいんだけど、どのようにすれば良いか分からない、という方も多いのではないでしょうか。本セッションでは、架空のお客様の相談を元に、AWS のソリューションアーキテクトが、適切な分析環境のアーキテクチャを検討していくところを見ていただくことで、クラウド上でのソリューション選択や、データレイクを作る意味等を学んでいただけます。

動画・資料

アーカイブ動画と資料は以下リンクよりご覧いただけます。動画につきましては2020/9/30までの限定公開となります。

セッションレポート

今回は実際にお客様(事業者)からの要望があったと仮定して、その要望を満たすには AWSにおいてどのようなアーキテクチャを作っていけばよいかを考えるという形で進められました。今回仮定とするお客様の要望は以下のようなものです。

雑貨のセレクトショップを経営している
実店舗での販売をしてきたが、最近はECやモバイルでの販売・マーケティングも行っている
オンプレミスとAWSのシステムにログがたくさんある
ログを分析してビジネスに活かしていきたい
データサイエンティストはいないが、SQLをかける人はいる
できるだけ素早く、運用負担の少ない形で分析を行いたい

クラウドで分析を行うことのメリット

マネージド

クラウドのメリットは「やれることが増える」というのもあるが、キーポイントは「やらなくていいことが増える」ということ
AWSのマネージドサービスやサーバーレスのサービスを使うと、管理などをAWSにオフロードして分析に集中できる

スモールスタート

小さく初めて、うまくいけば大きくするといったようなことができる
すぐに初めて、トライアンドエラーを重ねることができる
今回のように「どのような構成で分析を行ったらよいかよくわからない」という場合に有効

変更に強い

データ分析の肝は「データを一箇所に集めること」
分析のために、集めた大きなデータの型を変えるといった力仕事が必要
- コンピューティング性能を必要に応じてクイックに変更することができる
オリジナルの(生の)データを残しておけば、後から分析の方法変更が効く
- データ容量を気にせずS3にデータを置くことができる

アーキテクチャを考える

S3へのデータの集約

オンプレ→S3
- Direct ConnectやVPNでクラウドに接続
- Database Migration Serviceを使ってクラウドに簡単にデータを移すことも可能
EC2 →S3
- Weblogをfluentdのプラグインを使ってS3にデータを移す
- WeblogをfluentdからKinesis Data Firehoseを使ってS3にデータを移す

といった選択肢があるが、ニーズやファイルフォーマットによってこれらを使い分ける。

データの変換処理

「生データ」をS3にデータを収集後、ファイル形式やフォーマット変換処理にどのようなサービスを用いればよいか。

Lambdaで変換処理を行う
- サーバーレスで気軽に使うことができる
- 小さいファイルのフォーマット変換などに対してはいいが、15分の制約がある
GlueのPython shellで変換処理を行う
- Python shellを使うとLambdaの15分の制約を気にする必要がない
- すでに自前のPythonスクリプトなどがある場合には導入しやすい
その他
- EC2を立てて自前の変換処理スクリプトを実行する
- Fargateでコンテナ化された変換処理を実行する
- EMRを使ってHiveのプログラムを動かす
- AthenaのCREATE TABLE AS SELECT (CTAS) クエリの機能を使う
- SQLでデータを取ってきて新しいオブジェクトとしてS3に配置する

などのたくさんの選択肢があるが、要件に合わせて選択する。生データを残しているので、加工の選択肢を検証して選択することができる

データの変換後の分析

Athenaを使うと便利
- 構築不要でサーバーレスでSQLが使える
- サポートしているツールも多く、大規模演算にも耐えうる
- 今回のお客さんの用件だとAthenaが合っているかも
- クエリごとの課金になるが、ワークグループのコントロール機能でスキャン容量を決めて、ユーザー側でコントロール可能
その他色々なオプション
- Sagemakerを使ってJupiter Notebookで分析する
- 会社で今使っているBIツールをそのまま使う
- RDSでpostgreSQLやMySQLなど慣れたDBエンジンで分析する
- コストを明確に固定したい場合などはRDSのリザーブドインスタンスを使うと便利
- Redshiftをデータウェアハウスとして使う
- RDSとRedshiftの違いについて
  - RDSは汎用データベース。いろんなことに対応できるDBエンジン。
  - Redshiftはデータウェアハウス用途特化型。巨大な分析には使えるが、汎用性は減っていると言える。
  - ランダムな書き込みがパラレルに行われる場合などはRDSの方がパフォーマンスがでる
  - データの量よりは処理系でどちらを採用するか判断する
  - 細かいクエリが大量にあるような場合はRDS
  - 大量データをOLAP的に分析する場合はRedshift
- QuickSightに直接入れて、インメモリデータベースのSPICEを使って分析処理を行う

このようにクエリエンジンも多くの選択肢がある。変更が効くので、多くの検証を行って決めることができる。

データの活用

可視化
- QuickSightは簡単に使うことができる
  - GUIを使えるため、非エンジニアでも扱うことができる
- もちろんその他の可視化ツールを使うことも
予測
- Sagemakerを使ってデータサイエンティストが機械学習を用いて分析する
- Forcast
- データサイエンティストがいないような会社でも、簡単に使うことができる
- QuickSightのML insightで予測する